Drupal Hack Night

After reading Nielsen's recent post on mega dropdown menu's I've been working on the spec for a drupal module that would make implementing something like this doable in conjunction with the menu & block modules. If anyone has experience hooking into the menu theming functions it'd be great to have the learning curve shortened a bit there. It would also be great to get some designer input on possible default stylesheets for this thing.

The core theming hooks for menus, and the menu system as a whole in D6 doesn't provide any mechanism (afaik) for introducing flexible grouping into the menu structure to support mega menus.... you need to be able to rewrite menu_tree_output() from the looks of things. I need this too and i think a modification of the menu_block module would be a good start. It provides it's own menu_tree_output() to enable full control over theming arbitrary menu levels in a block.

It would be great to see afreemannc's specs...

I sort of have several levels of concern on my end.

First being how we "feed it" menu items without completely reinventing Drupal's Menus. (like for me, I find it a bit annoying that the "main" navigation is supposed to be the "navigation" menu, but all the drupal/user stuff is crammed in there too...). My ideal would to have some sort of javascript interface to a monolithic tree structure that you can then nab pieces of and direct to different menus. But it would have to still play nice with the core. (and yes, I know this is not really what this thread is about, but I'm curios what you're thinking as far as interface because realistically megadropdowns can handle 2-3 "levels" of nav and ideally would not orphan your deeper nav).

One, fairly clear and relatively simple idea I have is you create one big menu structure, and then you can choose a level of the hierarchy to "alias it out" as another menu name / block. Sort of how primary links can overtake secondary links but more adjustable. This would be less extension of the core. Maybe a separate project still, but possibly of benefit in general to those who want more from their menus.

Second being whether some of the intermediate steps between the menus and the mega-dropdowns should be packaged in a way that other developers can leverage them for other styles of menus. I'd have to say in this department, depending on how we access the menu information, there probably should be an abstract layer before you get to the megadropdowns as a UI component.

So maybe one (A) interface (or extension of the existing interfaces) for defining what chunks or branches define the menu(s) and making them accessible to another (B) interface that has options to configure the UI of the megadropdowns (with (C), other menu styles being possible as well if other developers wish it).

The third major area of discussion would be how much configuration of the UI to do in an admin menu, how much to leave up to theming, etc. Will we be able to agree on the general behaviors and implementation of MegaDrop downs?

How does all this relate to the experimentation you've done with the existing module interfaces?

EDIT: should we move this discussion to it's own home?

The way I see it existing core modules (menu, block) should provide 100% of the needed API to get this done, otherwise we're looking at deficiencies with core itself. Building some kind of advanced menu API is far beyond the scope of simply implementing megas, and should (in my mind anyway) be treated as a separate concept unless or until we run into a roadblock with the hooks currently available in core.

As far as standard behavior is concerned, the more I think on this the less point I see in administering one of these things via the Menu module. I'd say hook into Menu when menu items are created, have a separate glue table that keeps track of relationships between menu items and blocks in your mega, primary navigation elements could either be inherited from an existing menu or added on the fly and use a drag and drop interface (similar to blocks) to place combinations of subnav and block elements to build out your mega. And yes, I think this should probably have it's own home.

I've started a draft (google doc) for the initial specification. Those interested should message me with a valid email address and I'll share the doc. I'm open to suggestions re: moving the discussion. I think it's premature to create a separate group here though. Maybe IRC?

afreemanc:

Thanks for adding me to your spec sheet doc. I like where you are going, I will have to post my own notes, which, admittedly, are more conceptual and less implementation oriented. (so its good to know you already see a path to this).

The only question that really strikes me at this point is:

Why "import" a menu to mega-drop downs, instead of using the existing menu system? Is this to accommodate non-standard items? If so, there may be some module out there we can leverage that will address that concern and allow use of a single menu structure.

My main concern is that duplicating a menu might mean that if you are using that tree structure to generate more than one type of menu (like contextual side menus via menu_block). Obviously the ideal is that if you need to alter your menu structure, you do it once, in one place.

Import is a waste of time. I realized that once I'd spent a little time working on the module. However I disagree with your assertion that menu structure (or any data for that matter) should only be alterable from one place. I believe that (ideally) data should be alterable anywhere it's surfaced. FilmKnurd's description of how the interface should work is accurate IMO.

Lets shoot for 7:00pm Eastern on Tuesday 9-15-09. We can use #drupal-nc on freenode. Does that work for everyone?

i am fairly new to drupal, but from what i see in the interface that it would seem as though the core menu module would have to be coerced into accepting different data types as input.
that being said, the menu would almost have to be written or replaced via hooks in order to work.